home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-x400ops-mhs-service-04.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
67KB
|
1,740 lines
RARE WG-MSG Urs Eppenberger
Internet Draft SWITCH
February 1992
Expires: August 1993
Routing coordination for X.400 MHS services
within a multi protocol / multi network environment
Table Format V3 for static routing
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
It is intended that this document will be submitted to the IESG
for consideration as a prototype standard. Distribution of this
document is unlimited. Comments to the document may be sent to the
distribution list wg-msg@rare.nl of the RARE Working Group on Mail
and Messaging.
1 Abstract
The usage of the X.400 Message Handling System (MHS) is growing
rapidly, especially in the commercial world but much interest can
also be found in the academic and research community. New networks
and new addresses come into use each and every day. The underlying
technology for different X.400 networks can vary depending on the
transport network and the X.400 MHS implementations used. As a
large number of X.400 implementations now support multiple stacks,
this offers the chance of implementing a world wide message handling
service using the same electronic mail standard and, therefore,
without the need of gateways with service reduction and without the
restriction to a single common transport network. This, however,
leads to several problems for the MHS manager, two of which are:
- Where do I route new X.400 addresses and
- How do I connect to a MHS domain that uses an underlying
technology that I do not support.
Eppenberger Expires: August 1993 [Page 1]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
This document proposes short term solutions to these problems. It
proposes a strategy for maintaining and distributing routing
information and shows how messages can travel over different
networks by using multi stack MTAs as relays. Document formats and
coordination procedures bridge the gap until an X.500 directory
service is ready to store the needed connectivity and routing
information. The format has been designed to allow the information
to be stored in an X.500 directory service while managers without
directory service access may still use a table based approach.
The routing structure proposed can be applied to a global MHS
service but may also be used at a national level or even within an
organisation.
Many experts from IETF X.400-Operations Group and RARE Working
Group 1 on Message Handling Systems have read drafts of this
document and contributed ideas and solutions. I would especially
like to thank Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan
Cargille and Paul-Andre Pays.
This is the third version of a table format. The first one was in
use within COSINE-MHS for about two years. A second version with
major enhancements was then proposed which has been in use for the
past year. The third version will probably be the last one before
it will be possible to switch to dynamic, directory service based
routing.
2 Terminology
MHS community
One or more MHS domains form an MHS community. Mail exchange
between these MHS domains is defined by the coordination
procedures within this document. Examples of such communities are
the Global Open MHS service GO-MHS and the COSINE-MHS service.
MHS domain
One or more MHS subtrees form an MHS domain. This is a purely
administrative grouping of MHS subtrees. It is helpful, if
someone is responsible for several MHS subtrees, to refer to an
MHS domain instead of listing all the subtrees.
MHS subtree
An MHS subtree consists of the total of the mailboxes
addressable within a subtree of the X.400 OR address space.
Eppenberger Expires: August 1993 [Page 2]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
MHS domain of SWITCH in Switzerland, consisting of all
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
address.
RELAY
An X.400 MTA serving one or several MHS domains. Note that the
term WEP -Well Known Entry Point- has been used since the early
X.400ies (1987/88) until now, giving the wrong impression of a
single entry point (and therefore a single point of failure).
This document proposes to use the term RELAY, reflecting more
clearly the functionality of the MTA.
COSINE-MHS
The COSINE-MHS community is mainly formed by European X.400
service providers from the academic and research area, each of
which is a member of RARE. The COSINE-MHS community is used in
the annex as an example for the usage of this document in a
multinational environment.
3 Requirements
X.400 MTAs can communicate using different transport and network
protocol stacks. For this document the stacks used in a WAN
environment need to be considered:
Stack 1 Stack 2 Stack 3 Stack 4
Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONS
A common protocol stack is not the only requirement to enable
communication between two MTAs. The networks to which the MTAs
belong need to be interconnected. Some well known networks are
listed together with the stacks they use.
Network Stack Abbreviation
Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure EMPB 1,4 EMPB-X.25
US and European connectionless pilot 2 Int-CLNS
Internet 2,3 Internet
Note that several stacks may be supported over a single network.
Eppenberger Expires: August 1993 [Page 3]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
However communication between MTAs is only possible if the MTAs
share at least a common stack AND a common network.
Unlike SMTP/TCP/IP systems, there is no directory service
available which would allow an MTA to look up the next MTA to which
it should submit a message. Routing within X.400 will continue to
be table based until a solution using X.500 directory services is
available.
Furthermore it is not generally allowed to connect to any MTA even
on the same network without being registered on the destination MTA.
These restrictions require a large coordination effort and carefully
configured and updated systems.
4 Outline of the proposal
This proposal offers a solution for describing information about
X.400 message routing within an MHS community in RELAY and DOMAIN
documents. Basic information on the MHS community is documented in
the corresponding COMMUNITY document. All contact persons and RELAY
administrators can be found in PERSON documents. A future X.500
based solution may need extended information to overcome still
unsolved problems like optimal routing or traffic optimization for
messages with multiple recipients. The information collected for
the intermediate solution however is very basic. All established
coordination procedures will help and even speed up the future
introduction of an X.500 based solution.
4.1 The COMMUNITY document
For each MHS community there exists one single COMMUNITY
document containing basic information. First the contact
information for the central coordination point can be found
together with the addresses for the file server where all the
documents are stored. It also lists network names and stacks to
be used in the RELAY and DOMAIN documents. An MHS community must
agree on its own set of mandatory and optional networks and
stacks.
4.2 The RELAY document
Every MHS domain in the community may designate one or more MTAs
as RELAYs. These RELAYs accept incoming connections from the
RELAYs of the other MHS domains and in return are allowed to send
messages to these RELAYs. A RELAY is documented with all the
necessary connection information in the corresponding RELAY
document.
Eppenberger Expires: August 1993 [Page 4]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
4.3 The DOMAIN document
An MHS domain has a responsible person who sets up the routing
entries for the domain in the DOMAIN document. The primary RELAYs
listed in the DOMAIN document as serving this MHS domain must,
TOGETHER, offer at least connectivity to all networks and stacks
listed as mandatory in the COMMUNITY document. Optional RELAYs
may be added, generally with higher priority, to allow more
precise routing.
An MHS domain may also decide not to operate a RELAY. It will
then only need agreements with one or more RELAYs from other MHS
services which will relay for this domain. The domain itself,
however, must either create its own DOMAIN document or document
its MHS subtrees jointly with another MHS domain.
The structure of the DOMAIN document is very straightforward.
It starts off with one or more MHS subtrees, each on its own line.
After the domains follows a line indicating the responsible person
for the MHS subtrees mentioned. Finally the responsible RELAY(s)
are listed with appropriate priorities.
4.4 The PERSON document
All administrators and responsible persons are documented in
PERSON documents. The COMMUNITY, RELAY and DOMAIN documents
contain just keys pointing to a PERSON document. If such a person
can already be found in an X.500 directory service, then the key
consists of a Distinguished Name, else the key is just its OR
address.
4.5 Coordination
This approach requires an identified coordination point. It is
up to the MHS community to decide on the level of coordination and
support to be provided and on the funding mechanisms for such
activities. Basic information can be found in the COMMUNITY
document. The following list of support activities is considered
mandatory for an operational service:
- New RELAYs joining the service are tested and support is given
to create the RELAY document.
- New MHS domains joining the MHS community get assistance to set
up RELAY(s) and/or find appropriate RELAY(s) and to create
DOMAIN documents.
- Updated documents are announced to the RELAY managers and
responsible persons for the DOMAIN documents unless automatic
Eppenberger Expires: August 1993 [Page 5]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
distribution is used.
- All the RELAY, DOMAIN and PERSON documents are made available on
a file server together with the COMMUNITY document. The file
server must at least be reachable via email. MHS communities
with a big number of documents may consider additional access
methods like ftp and FTAM.
- Tools should be made available to manage routing tables for the
X.400 software used on the RELAYs or to fill in and check the
documents. The format of the documents has specifically been
chosen to enable the use of automated tools.
The RELAY managers must be aware that a large number of RELAYs
in an MHS community may require significant operational resources
to keep the local routing tables up-to-date and to constantly
monitor the correct functioning of the connections. On the other
hand more than one RELAY with a good connectivity to an MHS domain
improves the overall robustness of the domain and thus the QOS.
MHS communities may decide on additional mandatory requirements
for the operation of a RELAY. These may include a hot line, echo
services, exchange of statistics, response time to problem
reports, uptime of the RELAY, etc. This will ensure a certain
quality of service for the end users.
4.6 Routing
The proposal addresses MHS communities spanning several
organisations. But it may also be used to manage routing within a
single organisation or even a global MHS community.
Two kinds of mail relays are defined, the primary RELAYs and the
secondary RELAYs. A primary or secondary RELAY must allow
incoming connections from all other primary and secondary RELAYs
with a common stack. Primary RELAYs must be able to connect to
all other primary RELAYs which share a common stack. A secondary
RELAY must connect to at least one primary RELAY.
Each MHS community must define update procedures for the routing
based on the documentation. Automated update has to be studied
carefully.
An MHS community should also define procedures for new RELAYs
and MHS domains joining the service. Since the usage of X.400 is
growing rapidly a flexible but well coordinated way of integrating
new members into an MHS community is needed. The proposed
documentation format supports this by allowing primary and
secondary RELAYs. All RELAYs accept incoming connections from
each other. Sending messages can be done by using the primary
Eppenberger Expires: August 1993 [Page 6]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
RELAYs only. This allows new RELAYs to join the community as
secondary and to get primary status when traffic flow increases.
Secondary RELAYs may also require a longer testing period.
5 The documents
The definition is given in BNF-like syntax. The following
conventions are used:
| means choice
\ is used for continuation of a definition over several lines
[] means optional
{} means repeated one or more times
() is used to group choices
\" is used for double quotes in a text string
<CR> is a Carriage Return and means that the next section starts
on its own line.
The definition is complete only to a certain level of detail.
Below this level, all expressions are to be replaced with text
strings. Expressions without more detailed definition are marked
with single quotes '. The format and semantics should be clear
from the names of the expressions and the comments given.
Wherever the BNF definition requires a single blank, multiple
blanks may be used to increase the readability. Please note that
for some field values the number of spaces is significant.
Lines exceeding 80 characters should be wrapped at any
convenient blank except at blanks which are significant. The line
is continued with at least one trailing blank.
Comments may be placed anywhere in the document but only on
separate lines and without splitting wrapped lines. Such a
comment line must either start with a '#' sign followed by white
space and the comment or consist of a single '#' on a single line.
Some field values are case sensitive (TSEL, Password). In order
to handle this issue in a consistent way all keys and values must
use the same case as the BNF definitions.
The BNF definitions are ordered top-down. See Appendix B for an
alphabetically sorted list.
Eppenberger Expires: August 1993 [Page 7]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
A set of one COMMUNITY document and several RELAY, DOMAIN and
PERSON documents belong together. The detailed definitions can be
found in the following chapters.
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
5.1 Common Definitions
<DirectoryName> ::= 'Distinguished Name'
The string representation of a Distinguished Name is
defined in the IETF OSI-DS document 23. If a
Distinguished Name is used as a key in the documents,
then the information can be fetched from the directory
instead of checking the appropriate document. But as
long as not all managers in the same community have
directory access, the same information must also be
present in a document. Note that Distinguished Names
in the context of the routing documents are just used
as key strings to point to other documents.
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>
The 'community name' is a string identifying the MHS
community to be used in the first line of all
documents.
<UniqueRELAYkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
A unique key is needed to identify the RELAY. In
addition to the MTA name itself, it is proposed to use
OR address attributes of the management domain where
the RELAY resides. ADMD and PRMD fields are both
optional and may be used to guarantee uniqueness of the
key. The values used are irrelevant. Even non-
printable characters like @ or ! are acceptable. The
result is not an address but a key string. A
Distinguished Name may be used instead.
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
A unique key is necessary to make the links from the
documents where a responsible person or an
administrator is needed, to the PERSON documents. It
is either the OR address of the person or a
Eppenberger Expires: August 1993 [Page 8]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Distinguished Name (if the person is already registered
in the directory).
<Country-Code> ::= 'Two Character Country Code ISO-3166'
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
It has been used consequently all over the document.
This explains also the syntax of the <UniqueRELAYkey>
and the <MHS-subtree>. Examples:
S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
G=john; I=w; S=doe; P=org; A=rel400; C=aq;
<EMail> ::= "Address: " <X.400 address> <CR>
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
This syntax follows the attribute syntax of the X.500
directory based on CCITT E.123.
<int-pref> ::= 'international prefix'
<national number> ::= 'national telephone number'
A national number may be written with spaces and
hyphens to group the figures.
<extension> ::= 'local extension'
<Phone> ::= "Phone: " <tel-no-list> <CR>
One or more phone numbers
<Fax> ::= "Fax: " <tel-no-list> <CR>
One or more FAX numbers
<Mail> ::= "Mail: " 'postal address information' <CR>
The items of the postal address are separated by ' / '
wherever the next item goes onto the next line for a
printed address label. If the document is for an
international community, the address should include the
person's country.
Example:
Mail: SWITCH Head Office / Urs Eppenberger /
Limmatquai 138 / CH-8001 Zurich / Switzerland
results in the following mailing label:
SWITCH Head Office
Urs Eppenberger
Limmatquai 138
CH-8001 Zurich
Switzerland
Eppenberger Expires: August 1993 [Page 9]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
The <Update-info> contains also the format identifier.
The date of the last update of a document is given in
the form 'yymmdd'.
A start date must be set. A document can be published
this way before the information in it is valid. (This
is especially useful in absence of automated tools.
RELAY managers get more time to prepare their systems.)
An end date is used to set an expiration date for the
document.
<P-address> ::= 'String encoded Presentation Address'
The format of this string follows RFC1278, A string
encoding of Presentation Address and RFC1277, Encoding
Network Addresses to support operation over non-OSI
layers. See chapter 5.2 about the usage of macros in a
Presentation Address.
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
<Network-name> ::= 'Name of a network'
The network-name string identifies a network. A well
known key word should be chosen. (No '/' character is
allowed.)
Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
WIN, Janet,
<Network-service> ::= 'Name of a network service'
Examples: X.25, CONS, CLNS, TCP
<Transport-Protocol> ::= 'Name of a transport protocol'
Examples: TP0, TP2, TP4, RFC1006
Since network and stack information forms one string,
it identifies in an easy way a connection possibility
between two RELAYs. The COMMUNITY document defines the
strings to be used in the RELAY and DOMAIN documents.
Some examples:
Internet/TCP/RFC1006
Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4
(It is probably important to mention here that this
string has nothing to do with the format of a
Eppenberger Expires: August 1993 [Page 10]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
presentation address as defined by Steve Hardcastle-
Kille in RFC1278. The problem of networks using the
same address structure (X.121 DTEs, 4 Byte Internet
addresses) but not being connected is not addressed in
RFC1278 but solved by using the proposed service
identifier above in addition to the presentation
address. As long as there are network islands, there
is no other way than the addition of an 'island'-
identifier.
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
[[[["OU1="'OrganizationalUnit-name'"; "]\
"OU2=" 'OrganizationalUnit-name' "; "] \
"OU3=" 'OrganizationalUnit-name' "; "] \
"OU4=" 'OrganizationalUnit-name' "; "] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone>
<time> ::= 'hh:mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hours'
The operation information is needed to know the time
someone is reachable. This information is important
for communities spanning several time zones.
Use "UTC+" for time zones east of Greenwich. A simple
formula helps to calculate the current time at the
remote place:
local-time - local-displacement + remote-displacement =
remote-time
18:00 - (UTC + 1) + (UTC - 8) = 09:00
The <Time-zone> entry may be followed by a comment line
indicating when Daylight Saving Time is in effect.
This is especially reasonable for MHS communities
spanning continents on the northern and southern
hemisphere.
5.2 The COMMUNITY document
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
The first line of the COMMUNITY document specifies the
<Community-Identifier> to be used in the header of all
other documents belonging to the same community. It is
recommended to add a few comment lines to describe the
members of this MHS community.
Eppenberger Expires: August 1993 [Page 11]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<COMMUNITY-document-body> ::= <Coordination> \
{<Macro-definition>}{<Connections>}
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <Operation> <File-server>
Set of contact information for the coordination point
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]}
All documents must be available at least to the
managers of the MHS domains and the RELAYs through an
email server. If FTAM and FTP are also available, the
generation of automated update tools is much easier.
It is suggested to have a single server. If there is
only one, knowing a single X.400 OR address will allow
you to reach the server. However for FTP and FTAM more
system addresses may be possible depending on the
number of available network connections (or service
types as they are called in this document).
<email-server> ::= "Mail-server: "<X.400 address> <CR>
The email address of the file server.
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
In addition to the domain name of the server, an
account name and a password is given. In most cases
this will probably be something like "anonymous" and
"guest".
Some servers request the RFC822 address of the user.
This is documented by using the string 'user@domain' as
password entry. The meaning is not to use
'user@domain' literally as password while accessing the
server (even if this would generally work too since the
software often just checks the presence of an @ sign,)
but to use ones own RFC822 email address.
<FTAM-server> ::= "FTAM-server: " 'P-address' "; "\
<account-name> ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
The account name is often case sensitive. Some FTAM
server offer anonymous access with the account-name
ANON. Documenting an FTAM server with a Distinguished
Name is only allowed if the server is registered in the
directory.
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
Presentation addresses without the usage of macros are
generally unreadable. RFC1278 suggests a few macros.
All macros which are allowed in a community must be
Eppenberger Expires: August 1993 [Page 12]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
defined in the COMMUNITY document. It is recommended
to use the proposed macros in RFC1278 and add new ones
if necessary:
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X.25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
Note that at least one mandatory service type is
needed.
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
5.3 The RELAY document
<RELAY-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-document-Identifier> \
<RELAY-document-body>
A RELAY document contains the full description of a
single RELAY. Only one community is allowed. Since
some of the information is community dependent, it
would not be easily possible to have a single RELAY
document used in different communities.
<RELAY-document-Identifier> ::= "RELAY: <UniqueRELAYkey> <CR>
<RELAY-document-body> ::= <Status> <connection-info> \
<contact-info>
<Status> ::= "Status: " ("primary" | "secondary")
This defines if the RELAY has 'primary' or 'secondary'
status. See section 4.3 and 6 for more information.
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
More than one set of connection information may be
present for RELAYs supporting several networks and
protocol stacks.
Eppenberger Expires: August 1993 [Page 13]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
If the keyword none is present, then no password is
sent with the MTAname when this MTA initiates an RTS
connection or responds to an incoming connection.
Password: none
If the keyword secret is present, then the connection
needs a password which is not made publicly available.
(For example, a community might keep a list of the
passwords at the central coordination point. The list
would then be faxed to the RELAY managers.)
Password: secret
A password must be documented using the
value="password" notation. The double quotes around
the password are needed, consider the case of a single
blank as a password.
Password: value=" "
Password: value="nume-n-ine"
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> \
[<Service-priority>] <CR>
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984
See ISO 10021-6, Section 3, chapter 11.1 for more
details on this matter. X.400(84) systems only support
mts-transfer-protocol-1984.
<Service-priority> ::= "; " 'Integer 0..99'
The lowest Integer corresponds to the highest priority
as in DNS. It is possible to set different priorities
for each service type. This may be chosen, for
Eppenberger Expires: August 1993 [Page 14]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
example, to distribute the load amongst different
networks according to their available bandwidth.
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
Since called and calling network addresses may differ
in certain configurations and some X.400 systems do
validation on calling network addresses, it is
important to have this information in the RELAY
document. (Note: a calling X.121 address might change
if the X.25 switch is reconfigured. This will stop a
RELAY from connecting to other RELAYs using address
validation without having changed anything at the
higher layers!)
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
It is optional to provide HW/SW information.
Experience, however, has shown that a number of
communication problems were more easily identified and
solved with this information present and up-to-date.
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
This is a useful but optional extension to the
documentation.
The <MHS-subtree> is local to the RELAY. The <MHS-
subtree> attributes might be used together with
S=nosuchuser; to do connectivity and availability
tests.
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
Some of the RELAYs might offer an echo server
functionality. It does make sense to document this in
the RELAY document for test purpose. This field is
optional.
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
The contact details for the RELAY administrator can be
found in the appropriate PERSON document. It is
possible to document a whole team using a distribution
list if this is desired. It is generally better to
document one or more 'real' persons.
5.4 The DOMAIN document
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
Eppenberger Expires: August 1993 [Page 15]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
Note that it is not allowed to have equal <Domain-
entry> lines in different DOMAIN documents belonging to
the same MHS community. A Domain-entry line can only
appear in one DOMAIN document.
<OR-matching> ::= ( "* " | "= " )
This qualifier defines how the following OR address
attributes should be handled for the routing algorithm.
If a '*' is present, a destination address of a message
is matched by the "Domain:" entry if at least the OR
address attributes in the "Domain:" entry are equal to
the destination address.
If a "=" is present, a destination address of a message
is matched by the "Domain:" entry if there are exactly
the same OR attributes in the destination address as in
the "Domain:" entry. (This restriction works for OU4,
OU3, OU2, OU1, O, P, A and C only.)
Example:
a) Domain: * P=switch; A=arcom; C=ch;
b) Domain: = P=switch; A=arcom; C=ch;
The address S=eppenberger; P=switch; A=arcom; C=ch;
matches both cases, a) and b).
The address S=eppenberger; O=unibe; P=switch; A=arcom;
C=ch; matches only case a).
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
This is the person responsible for the listed domains.
His task is to get the agreement of the relaying RELAYs
and keep the DOMAIN document up-to-date. This person
is the only one authorized to make changes to this
document. Note that multiple administrators may be
listed.
<Relay> ::= "Relay: " \
'UniqueRELAYkey' "; " \
<RELAY-Priority> <CR>
The priority is used to define the sequence in which
different RELAYs may be tried in case of failure. A
lower integer corresponds to a higher priority as in
DNS. Priorities 0..49 are used to indicate backup
RELAYs. Priorities 50..99 are used for RELAYs not
acting as backup but as relay service provider for a
network service type not supported by the main RELAY.
<RELAY-Priority> ::= <Integer 0..99>
Eppenberger Expires: August 1993 [Page 16]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
5.5 The PERSON document
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation>
<Name> ::= "Name: " 'name of person' <CR>
The name of the person is given. The issue of the
character set problem is not addressed in this
document. Especially international communities should
restrict themselves to IA5 or ASCII.
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
This is the RFC-822 address of the person. It is often
a big help to know the RFC822 address of someone, for
example if the X.400 system is not reachable. This is
also the reason why it is possible to provide multiple
OR and RFC822 addresses. The first one is considered
the primary one.
6 Routing rules
All the users within the MHS community have the right to send
messages to each other. The general agreement is that the RELAY
infrastructure is used according to the following routing rules.
More direct connections based on bilateral agreements are fully
accepted.
A primary or secondary RELAY must allow incoming connections from
all other primary and secondary RELAYs with a common stack. Primary
RELAYs must be able to connect to all other primary RELAYs which
share a common stack. A secondary RELAY must connect to at least
one primary RELAY.
A message arriving at a RELAY must either be sent to the next
RELAY based on the DOMAIN documents of the MHS community or it is
sent to an MTA closer to the destination based on local routing
decisions. The following algorithm must be used when forwarding a
message to the next RELAY:
1 Select the relevant DOMAIN document by searching for a match of
the Recipient address in the message with the entries in the
'Domain: ' lines. Extract the list of RELAYs from the DOMAIN
document.
Eppenberger Expires: August 1993 [Page 17]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
If your own RELAY appears in this list, this indicates one of the
following:
- You offered relay services for another RELAY with higher
priority. Continue with step 2 to decide on the next RELAY.
- Your RELAY is the final destination according the DOMAIN
document of your community. You need to forward the message to
the final destination according local routing information.
2 From the list of RELAYs select those that have at least one common
network service type with your own RELAY.
3 Now delete all secondary RELAYs from the list where no direct
connection is desired. For remaining RELAYs in the list no
difference is made anymore between primary and secondary status.
4 Select from this reduced set of RELAYs the one with the highest
RELAY-priority. If there is more than one RELAY having the same
priority, then select a RELAY of your choice. If your own RELAY
appears in that list, then you are not allowed to send to a RELAY
with lower or equal priority.
5 If there are no service-priorities set in the corresponding RELAY
document indicating which service type to use, you are free to
choose the service type for connecting to the RELAY. However, if
there are specific priorities set then select the service type
with the highest priority.
6 If the connection fails then try other service types in the
sequence of descending priority.
7 If no connection works for the selected RELAY, then check in the
list for the one with the same priority, if possible, or else
select one with the next lower priority. If there is another
RELAY with a RELAY-priority between 0..49, then select it and
proceed at step 5. Without another RELAY to try the currently
selected RELAY will be retried.
6.1 How to use RELAY-priorities
An example helps to explain the usage of RELAY-priorities.
Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory
service types in the community REMOTEmail. The MHS domain
P=REMOTE; A=ARCOM; C=CH; operates MTA-B, only connected to public
X.25. A second RELAY which is connected to both, Internet and
public X.25 is needed to offer relay services. A connection using
Internet is considered cheap, somebody else pays the leased lines.
Both service types are available at MTA-A. Since MTA-B is the
only RELAY responsible for relaying messages to P=REMOTE; A=ARCOM;
Eppenberger Expires: August 1993 [Page 18]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
C=CH; to the final destination it must have the highest priority.
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 90
RELAY: P=RELAYC; A=ARCOM; C=CH;MTAname=MTA-C; 30
__________________________
+-------+ X.25 +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
TCP/IP \ /X.25
+-------+
| MTA-C |
+-------+
If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH;
then the rules of chapter 6 are evaluated:
1 MTA-B and MTA-C are possible destinations
2 MTA-B and MTA-C are reachable from MTA-A
3 MTA-B is a primary RELAY (not relevant in this example)
4 MTA-B has the highest priority.
5 MTA-B doesn't have specific service type lines documented.
MTA-A chooses public X.25, since it is the only possibility
to connect to MTA-B.
6 No other service types are available if the connection
fails.
7 MTA-C has a priority of 30, it is not a backup RELAY. MTA-A
must spool the message and try to connect directly to MTA-B.
The organisation running MTA-A could save money by sending
messages for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C.
Since the connection between MTA-C and the destination MTA-B is
also expensive, the organisation running MTA-C would have to pay
for external relay traffic. Setting a lower priority for MTA-C
forces the other RELAYs with public X.25 connectivity to take
their share of the cost.
Note that forcing other RELAYs to use a specific stack should be
avoided wherever possible by offering RELAYs with equal priority
for all mandatory network services. This can be an important
financial issue for MHS communities spanning several
organisations, it is not relevant in general for an MHS community
Eppenberger Expires: August 1993 [Page 19]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
within a single organisation.
6.2 How to use RELAY-priorities for backup RELAYS
Two RELAYs offer real backup connectivity for the MHS domain
P=REMOTE; A=ARCOM; C=CH;. It is therefore possible to set RELAY
priorities in the range of 50..99 for both RELAYs. MTA-B will be
the preferred one since it has the higher priority. If the
connection to MTA-B fails, a sending RELAY may immediately try to
connect to MTA-C.
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 90
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 80
__________________________
+-------+ +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
\ +-------+
-----------+ MTA-C |
+-------+
6.3 Load Sharing
It is possible to set equal priorities to do some sort of load
sharing. However, most implementations are not able to do random
selection of RELAYs with equal priorities but have a fixed
configuration. If load sharing is really needed then it is
suggested to split up the MHS domain into several MHS subtrees and
document them separately with a set of RELAYs with different
priorities.
An example is provided for illustration of the first possibility
with equal RELAY-priorities:
Eppenberger Expires: August 1993 [Page 20]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 90
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 90
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) /
) +-------+/
)--+ MTA-C |
_) +-------+
And here is an example where the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
DOMAIN document: Note that both RELAYs serve as backup RELAYs.
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 90
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 80
Community: REMOTEmail
Domain: * O=Big-Org;P=REMOTE; A=ARCOM; C=CH;
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 90
RELAY: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 80
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) \/
) /\ ____________________________________
) +-------+ ( )
)--+ MTA-C |--( O=Big-Org;P=REMOTE; A=ARCOM; C=CH; )
_) +-------+ (____________________________________)
7 Open issues
Currently there are about 40 RELAYs within the COSINE-MHS service.
A rough guess is that a network with about 60 RELAYs is still
manageable provided there are automated tools for MTA configuration.
If there are more MTAs applying for RELAY status in an MHS
community, then either an X.500 based solution should be ready or a
core set of about 30 well operated super-RELAYs should form a
backbone, documented within a specific MHS community.
Since the RELAY document contains information about the supported
X.400 version (84 or 88), it is possible for an X.400(88) system to
select with higher priority an (88)RELAY. The rules in chapter 6
could be modified to select X.400(88) systems first if the sending
Eppenberger Expires: August 1993 [Page 21]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
RELAY is an (88) system itself. The issue of how to establish an
X.400(88) RELAY infrastructure within an MHS community is for
further study.
Security Considerations
Security considerations are not discussed in this memo.
Appendix A Document examples for the COSINE-MHS community
Instead of creating artificial documents to show an example
document set, this appendix contains extracts from a real
operational X.400 service. The research and development community
in Europe has used X.400 for several years. This proposal was
initially written to address this community only and solve the
urgent routing and coordination problems. Contributions from
different experts have made it more flexible and therefore hopefully
useful for other MHS communities.
Eppenberger Expires: August 1993 [Page 22]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Appendix A1 The COMMUNITY document
Community: COSINE-MHS
# The COSINE-MHS service is a MHS community formed by the European
# academic and research networks with additional contacts in all
# other continents.
#
# The coordination is done by the COSINE-MHS project team.
#
Update: FORMAT=V3; DATE=921218; START=930201
#
Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
Phone: +41 1-262-31-43
Fax: +41 1-261-81-88
#
Mail: SWITCH Head Office /
MHS Coordination Service /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+1
#
Mail-server: S=mhs-server; O=switch; OU1=nic;
P=SWITCH; A=ARCOM; C=CH;
FTP-server: nic.switch.ch; cosine; user@domain
#
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
Macro: IXI TELEX+00728722+X.25(80)+06+
#
Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most X.400
# applications and mandatory in X.400 anyhow.
#
Mandatory-Service: Internet/TCP/RFC1006
# The Internet, standing for the global TCP/IP network of the
# research and development community
# RFC1006 is considered a solution to ease migration to OSI. It will
# be replaced by TP4/CLNS as soon as a reliable service is
# available.
#
Optional-Service: Int-CLNS/CLNS/TP4
# The RARE Connectionless pilot service. Current participants are
# NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
#
Optional-Service: EMPB-X.25/X.25/TP0
# The International X.25 Infrastructure covering most countries in
# Europe. The absence of volume tariffs make it a preferred choice.
Eppenberger Expires: August 1993 [Page 23]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Appendix A2 Example of a RELAY document
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
#
RELAY: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
#
Status: primary
#
Password: none
RTS-dialog-mode: MONOLOGUE
#
Called-address: Public-X.25/X.25/TP0;
"591"/Int-X25(80)=22847971014520+CUDF+03010100;
MTS-TP-84
Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014520;
#
Called-address: Internet/TCP/RFC1006;
"591"/Internet-RFC-1006=chx400.switch.ch;
MTS-TP-84
Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=chx400.switch.ch
#
Called-address: EMPB-X.25/X.25/TP0;
"591"/IXI=20432840100520+CUDF+03010100;
MTS-TP-84
Calling-address: EMPB-X.25/X.25/TP0;
IXI=20432840100520;
#
Calling-address: Int-CLNS/CLNS/TP4;
"591"/NS+39756F11111111010000014560AA00040005E100;
MTS-TP-84
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
# For X.400(88) over CLNS
#
Calling-address: Int-CLNS/CLNS/TP4;
"592"/NS+39756F11111111010000014560AA00040005E100;
MTS-T
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
#
LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
EchoServer: S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
Administrator: CN=Felix Kugler, O=SWITCH, C=CH
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Eppenberger Expires: August 1993 [Page 24]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Appendix A3 Example of a DOMAIN document
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
##
Domain: * P=SWITCH; A=ARCOM; C=CH;
Domain: * P=SANDOZ; A=ARCOM; C=CH;
Domain: * P=ABB; A=ARCOM; C=CH;
Domain: * P=UBS; A=ARCOM; C=CH;
Domain: * P=ISREC; A=ARCOM; C=CH;
Domain: * P=ALCATEL; A=ARCOM; C=CH;
Domain: * P=ITU; A=ARCOM; C=CH;
Domain: * P=OSILABMAIL; A=ARCOM; C=CH;
Domain: * P=WHO; A=ARCOM; C=CH;
Domain: * P=CERN; A=ARCOM; C=CH;
Domain: * P=CERBERUS; A=ARCOM; C=CH;
#
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
RELAY: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 0
#
RELAY: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10
Appendix A4 Example of a PERSON document
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
#
Key: CN=Christoph Graf, O=SWITCH, C=CH
#
Name: Christoph Graf
#
Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
RFC822: Graf@switch.ch
#
Phone: +41 1 2565454
Fax: +41 1 2618133
#
Mail: SWITCH Head Office /
Christoph Graf /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+1
Eppenberger Expires: August 1993 [Page 25]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Appendix B BNF Definitions
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> \
[<Service-priority>] <CR>
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
<COMMUNITY-document-body> ::= <Coordination> \
{<Macro-definition>}{<Connections>}
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <File-server>
<Country-Code> ::= 'Two Character Country Code ISO-3166'
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<DirectoryName> ::= 'Distinguished Name'
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
Eppenberger Expires: August 1993 [Page 26]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
<EMail> ::= "Address: " <X.400 address> <CR>
<email-server> ::= "Mail-server: "<X.400 address> <CR>
<extension> ::= 'local extension'
<Fax> ::= "Fax: " <tel-no-list> <CR>
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]}
<FTAM-server> ::= "FTAM-server: " 'P-address' "; "\
<account-name> ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
<int-pref> ::= 'international prefix'
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
<Mail> ::= "Mail: " 'postal address information' <CR>
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
[[[["OU1="'OrganizationalUnit-name'"; "]\
"OU2=" 'OrganizationalUnit-name' "; "] \
"OU3=" 'OrganizationalUnit-name' "; "] \
"OU4=" 'OrganizationalUnit-name' "; "] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
<Name> ::= "Name: " 'name of person' <CR>
<national number> ::= 'national telephone number'
<Network-name> ::= 'Name of a network'
Eppenberger Expires: August 1993 [Page 27]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<Network-service> ::= 'Name of a network service'
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone>
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
<OR-matching> ::= ( "* " | "= " )
<P-address> ::= 'String encoded Presentation Address'
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> ::= "Phone: " <tel-no-list> <CR>
<Relay> ::= "Relay: " \
'UniqueRELAYkey' "; " \
<RELAY-Priority> <CR>
<RELAY-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-document-Identifier> \
<RELAY-document-body>
<RELAY-document-body> ::= <Status> <connection-info> \
<contact-info>
<RELAY-document-Identifier> ::= "RELAY: <UniqueRELAYkey> <CR>
<RELAY-Priority> ::= <Integer 0..99>
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
<Phone> <Fax> <Mail> <Operation>
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
Eppenberger Expires: August 1993 [Page 28]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
<Service-priority> ::= "; " 'Integer 0..99'
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
<Status> ::= "Status: " ("primary" | "secondary")
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
<time> ::= 'hh:mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hours'
<Transport-Protocol> ::= 'Name of a transport protocol'
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
<UniqueRELAYkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
Eppenberger Expires: August 1993 [Page 29]
INTERNET-DRAFT Routing Coordination for X.400 Services February 1993
Author's Address
Urs Eppenberger
SWITCH Head Office
Limmatquai 138
CH-8001 Zurich
Switzerland
Phone: +41 1 261 8112
Fax: +41 1 261 8133
EMail: Eppenberger@switch.ch
S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
Eppenberger Expires: August 1993 [Page 30]